The invention is in the field of transaction processing, and more particularly concerns the maintenance of consistency between a primary database and a replica database by applying in parallel to the replica database, redo records from the transaction log of the primary database.
In the prior art of transaction processing, a primary database may be replicated at a remote location. The purpose of the remote database may be to provide backup to the primary database in the event of media failure in the primary. In order to ensure consistency between the database and its replica, processing of the primary database must be reflected in the replica database. Throughput for application of record processing to the replica must be at least as good as that achieved by the transaction processing system for the primary database; resource consumption at the replica processing should be low relative to the consumption of the transaction processing system as a whole. Serialization is required to ensure that the database is transaction-consistent with, and identical to, the primary database. Availability for the primary database should not be reduced by the addition of transaction processing for the replica.
In the prior art, database replication is exemplified in the use of synchronous distributed database technology. The System R STAR prototype of the IBM Corporation is a synchronous distributed database system which has provision for storing a consistent copy of a database in two locations. However, in their present practice, synchronous distributed database systems require the exchange of a significant number of messages to effect the processing required for maintaining consistency between the databases, and utilize database serialization in the form of locking.
Database media recovery processing includes the well-known forward recovery process in which a database unit is reconstructed by updating ar earlier version with recovery data recorded in a log, or journal. In this regard, the original version of the database unit is saved in stable storage. When a failure destroys the current copy of a database, the last current version of the database unit is reconstructed by restoring the saved version of the unit and then applying from the log changes to the saved version in the same order in which they were made to the lost version.
Use of forward recovery in a synchronous distributed database "mirrors" the original transaction processing. Since changes to the primary database are logged in the same sequence in which they occurred, the log data could be processed in parallel by first obtaining the locks originally held, and then passing from the log, the redo records in parallel. In this operation, a single recovery process would handle all records for a given transaction, holding all the locks for that transaction until the reconstruction is completed, and then releasing the locks. This recovery solution is limited by the fact that all locks for a particular transaction must be obtained by a single process to ensure that lock conflicts do not occur that would prevent replication of the original sequencing. This retards parallelism until after locks are obtained, and prevents performance of any work if any lock is unavailable.
In pending U.S. patent application Ser. No. 07/059,666, now abandoned, assigned to the assignee of this patent application, use is made of multiple queues of log records to be reapplied to a database during restart processing. It is pointed out in this application that updates to different database units can be applied in different orders than the order represented in the log without violating any correctness properties.
Agrawal, in "A Parallel Logging Algorithm for Multi-Processor Database Machines", DATABASE MACHINES: Fourth International Workshop, March, 1985, propounds the parallel writing of log records to multiple logs but, during recovery, processes these logs serially through a single "back-end" processor. In Lyon, "Design Considerations in Replicated Database Systems for Disaster Protection", IEEE Computer Conference, Spring, 1988, it is stated that a remote database facility extracts updates from an active database's journal and applies them to a backup database.